spec(tenstorrent): trace-runner feasibility spike — NO-GO for T=1 decode - #541

…_topk -- remove the literal bounds (#505)

Lands the #505 fix: DsaTopkKernel sized `bool chosen[512]` and `int64_t
picked[64]` by literal while index_topk is 512 (V4-Flash) / 1024 (V4-Pro).
MEASURED on dgx.casa (GB10, sm_121a): the pre-fix kernel at Flash's own width
takes `cudaStreamDestroy: an illegal memory access` and SIGABRTs; after the
two-pass threshold rewrite the suite is 23/23 with 83913/83913 assertions and
0 skipped, re-verified from the merged tree with CUTLASS + FlashAttention-2
hard-verified in that run's own configure log.

The fix removes the bounds rather than asserting them, so there is no
configurable limit left to outgrow, and it drops the O(topk^2) emit sort.

FRESH REVIEW: PASS. An independent reviewer reproduced both the defect and the
fix on real sm_121a hardware, fuzzed 3,000,081 shapes across three independent
implementations (host reference, kernel transcription, and its own O(n^2)
rank-count oracle) with ZERO divergence, and ran a 12-row device mutation table.
It found no blocking issue and 6 non-blocking findings, addressed in a follow-up.
Notably it confirmed the tie-heavy case is uniquely load-bearing: it is the only
case that catches a tie-break inversion or a value-only threshold.

CI: windows-msvc-cpu and windows-msvc-vulkan are red at the repo-wide BASELINE,
not from this change -- the same two jobs fail on #539, #541 and on #511 which
already merged, and this PR's own log shows every target building with no
`error C####`, failing instead in the release-packaging PowerShell step.

Merged on direct developer instruction after the requested review pass.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]

…opk, and correct two guard-comment overclaims (#552)

Lands the six findings from the fresh review of #505, which returned PASS after
failing to find any input where the two-pass threshold selection diverges from
`DsaTopkSelect` -- 3,000,081 fuzzed shapes across three independent
implementations, zero divergence.

CODE: `DsaTopkLaunch` now checks `cudaGetLastError()` after the launch and refuses
non-positive `topk` to match the host reference, which previously asserted while
the device arm silently returned an empty vector.

TESTS: two new device cases. One drives the window clamps -- under-run, over-run,
both at once, and an in-range control -- which nothing exercised before. One
asserts BOTH arms refuse topk=0 and topk=-1.

PROSE: the `w < topk` guard comment claimed to defend against a NaN row writing
past its own row. That cannot occur: pass 2's predicate is satisfied by exactly
rank(th) <= topk elements and a NaN never satisfies it either. Corrected to
belt-and-braces, bounded by construction. "Strictly cheaper" is now scoped to a
comparison with the old kernel, not fitness for the real geometry.

REFUTED IN FLIGHT: finding 4 held that the launch check would make the next fault
attributable to this launch. The arm built to demonstrate it disproved it -- the
pre-fix kernel WITH the check still reports `cudaStreamDestroy: an illegal memory
access`, because a stack-overflow fault is asynchronous while `cudaGetLastError()`
covers launch-configuration errors. The check is kept and its comment now says
what it actually does; claiming otherwise would have repeated finding 1's defect
inside the change that exists to correct one.

DEVICE ARMS on dgx.casa (GB10 sm_121a), each a fresh nvcc rebuild from a pristine
kernel with the binary mtime verified to advance, scoped with `-tc=` never `-ts=`,
under `flock $HOME/gpu.lock`: baseline 6/6 SUCCESS; no_topk_guard FAILURE;
no_ws_clamp exit=134 CRASHED; no_we_clamp 1052 failed assertions; no_launch_check
SUCCESS (unobservable by construction); prefix_with_check exit=134; restored full
suite 25/25 with 90062 assertions, 0 skipped, SUCCESS. Both new cases have teeth
against the mutation each was written for.

CPU 25/25 and 13/13, preflight fully clean including the contention-sensitive
floor harness. Windows MSVC red is the repo-wide baseline (same two jobs fail on
#539, #541 and on #511 which already merged; no `error C####`, the failure is the
release-packaging PowerShell step).

Merged on direct developer instruction.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]